Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

CHAPTER 13
Standard Error Handlers

Chapter 12, “Error Handling Fundamentals,” explains in general how error handlers work. This chapter describes several specific error handlers you can use to cope with unexpected errors in your final compiled application.

When an unexpected error occurs, the program has two goals: to continue running safely and to notify you of the error so you can fix the problem. Chapter 12 described several techniques you can use to help a program continue running safely. For example, if every routine cleans up any data global structures it has modified, it is easier for calling routines to survive the failure.

There are several ways a program can report an error to developers. Some possibilities include:

•  Presenting a message to the user who then reports the message to developers

•  Writing a message into a file

•  Creating a new record in a database

•  Sending email to developers

The following section explains a systematic approach to error treatment that allows a program to trap and handle as many errors as possible. The rest of this chapter describes specific error handlers that use the previously listed methods to notify you and other developers when an error occurs.

Use a Systematic Approach

Use a systematic approach to ensure that the program catches every error. Agree with other developers on the strategy to take. If you all use the same methods, your error handlers will be easier to understand.

Most of a program’s code is executed by an event handler or by the Main subroutine if one is selected. To trap every error possible, event handlers and Main should always have error handlers that are prepared to handle any kind of error. Then even if the routines called by this code do not have error handlers of their own, these error handlers will catch the error.

When an event handler traps an error caused by a routine it calls, it cannot give very detailed information. It can check the Err object to learn the error’s code and description, but it cannot determine where the error occurred. You can get a more precise location for the error if you place an error handler in every routine in the program.

One strategy for systematically handling every error begins by placing an error handler in every routine in the application. The following code shows the error handler’s initial structure. All this code does is present a message box describing the error.

Private Sub MySub()
    On Error GoTo MySub_Error

    ‘ Do whatever the routine needs to do.
       :

    Exit Sub

MySub_Error:
    ‘ Handle unexpected errors.
     MsgBox “Unexpected error ” & _
    Format$(Err.Number) & _

       “ in MyModule.MySub.” & vbCrLf & _

       Err.Description

     ‘ Clean up any modified data structures.
         :

     ‘ Reraise the error.
     Err.Raise myappGradeRatioError, _
         “MyApplication.MySub”, _
         “Divide by zero calculating grade ratio.”
End Sub

As you develop and test the program, you will discover errors you had not anticipated. When you learn about new errors that may occur, analyze them to decide how they should be handled. If an error can be prevented, modify the code to prevent it.

If the error handler can take action to fix a problem, add the proper code to the error handler. For example, if the error indicates that a floppy disk is not present, the error handler might tell the user and ask if it should cancel its operation or try to read the file again. It can then exit the routine or use a Resume statement to try to read the file once more. See Chapter 12, “Error Handling Fundamentals,” for more information on this kind of behavior.

If you find an error that seems likely to occur and that you know the program cannot handle, add code to the Select statement to exit the routine appropriately. The following code shows how a routine might exit when it encounters a divide by zero error.

MySub_Error:
    Select Case Err.Number.
        Case 11
           ‘ Divide by zero. We cannot handle this.
            ‘ Clean up any modified data structures.
                 :

            ‘ Reraise the error.
            Err.Raise myappGradeRatioError, _
                “MyApplication.MySub”, _
                “Divide by zero calculating grade ratio.”

    ‘ Handle other errors
           :

     Case Else
       ‘ Handle unexpected errors.
             :
   End Select
End Sub

Even after you have thoroughly tested and debugged the application, the Else clause in the error handler’s Select statement handles errors you did not encounter while testing.

Catch Error Events

Ideally, a control handles its own errors and the program never needs to know something is amiss. For critical errors, a control should raise an Error event. To be certain your program catches this kind of error, check all nonstandard controls for Error events. If a control has an Error event, write an event handler to determine what has happened. Handle the situation as you would in a normal Visual Basic error handler.

A poorly designed control may raise an exception or allow an error to pass untrapped. In that case, the program may be unable to trap the error and it will crash. For example, suppose the user’s clicking on the control makes it enter a calculation that generates a divide by zero error. Because the main program’s code is not running, it cannot trap the error. If the control does not handle the error, the program crashes.

There is little you can do about this kind of error unless you have access to the control’s source code.

Present Error Messages

The simplest strategy for handling errors is to describe the error to the user. The user can then tell you and other developers about the error. The following code shows a minimal error handler. It simply invokes subroutine ShowErrorMessage to display the error message.

Private Sub MySub()
    On Error GoTo MySubError

    ‘ Do whatever this routine needs to do.
         :

    Exit Sub

MySubError:
    ‘ Display a non-speecific error message.
     ShowErrorMessage “ShowError.cmdRaiseError_Click”
     Exit Sub
End Sub

Subroutine ShowErrorMessage uses the MakeErrorMessage function to build an appropriate error message. If the program’s DEBUG_MODE constant is set to True and the Err.HelpFile value is not blank, the message box displays a Help button. During design, you can click on the Help button to get information that may help you understand the error. This information will be meaningless to a user who is not a programmer, so the Help button is not displayed when DEBUG_MODE is False. Note that the MsgBox function does not provide these help features in Visual Basic 4 and earlier versions.